home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-haller-auth-requirements-00.txt < prev    next >
Text File  |  1993-07-26  |  25KB  |  530 lines

  1.  
  2.   INTERNET DRAFT                                         Neil Haller, Bellcore
  3.                                                          Randall Atkinson, NRL
  4.                                                          August 1993
  5.  
  6.  
  7.                   Internet Authentication Requirements
  8.  
  9.  
  10.   STATUS OF THIS MEMO
  11.  
  12.      This documentis an Internet Draft.   Internet  Drafts  are  working
  13.      documents  of  the  Internettt  Engineering Task Force (IETF), it's
  14.      Areas  and  Working  Groups.  Note  that  other  groups  maay  also
  15.      distribute working documents as Internet Drafts.
  16.  
  17.      Internet Drafts are draft documents valid  for  a  maximum  of  six
  18.      months.  Drafts  may  be  updated,  replaced, or obsoleted by other
  19.      documents at any time.  It is ot appropriate to use Internet Drafts
  20.      as  reference  material  or  to  cite them other than as a "working
  21.      draft" or "work in progress."
  22.  
  23.      To learn the current status of any Internet Draft, please check the
  24.      1id-abstracts.txt  listing  contained in the Internet-Drafts Shadow
  25.      Directories  on  nic.ddn.mil,  nnsc.nsf.net,  ftp.nisc.sri.com,  or
  26.      munnari.oz.au.
  27.  
  28.      Distribution of this memo is unlimited.  It expires on February  1,
  29.      1994.
  30.  
  31.  
  32.   ABSTRACT
  33.  
  34.   The authentication  requirements  of  computing  systems  and  network
  35.   protocols  vary  greatly  with  their intended use, accessibility, and
  36.   their network connectivity.  This document  describes  a  spectrum  of
  37.   authentication   technologies   and   provides  guidance  to  protocol
  38.   developers on what kinds of authentication might be suitable for  what
  39.   kinds of protocols and applications used in the Internet.
  40.  
  41.   DEFINITION OF TERMS
  42.  
  43.   This section briefly defines some of the terms used in this  paper  to
  44.   aid the reader in understanding the draft.
  45.  
  46.      Active Attack:  An attempt to gain authentication or  authorization
  47.             by  inserting  false  packets  into  the  data stream.  (See
  48.             passive attacks and replay attacks.)
  49.  
  50.      Authentication:  The verification of the identity of the source  of
  51.             information,   possibly   including  verification  that  the
  52.             information has not been tampered with since being sent.
  53.  
  54.      Authorization:   The  granting  of  access  rights  based   on   an
  55.             authenticated identity.
  56.  
  57.      Confidentiality: The protection of information so that someone  not
  58.             authorized   to  access  the  information  cannot  read  the
  59.             information even though the unauthorized  person  might  see
  60.             the  information's  container (e.g. computer file or network
  61.             packet).
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.                                             Atkinson & Haller  -  Page 2
  69.  
  70.      Encryption: A mechanism often used to provide confidentiality.
  71.  
  72.      Integrity:   The  protection  of  information   from   unauthorized
  73.             modification.
  74.  
  75.      Passive Attack:  An attack on an authentication system  that  takes
  76.             inserts no data into the stream, but instead relies on being
  77.             able to passively monitor  information  being  sent  between
  78.             other  parties.  This information could be used a later time
  79.             in what appears to be a valid session.  (See  active  attack
  80.             and replay attack)
  81.  
  82.      Plain-text:  Unencrypted text.
  83.  
  84.      Replay Attack:  An attack on an authentication system by  recording
  85.             and  replaying  previously  sent valid messages (or parts of
  86.             messages).  Any constant authentication information, such as
  87.             a password or electronically transmitted biometric data, can
  88.             be recorded and used later to forge messages  that  appeared
  89.             to be authentic.
  90.  
  91.      Symmetric Cryptography: An encryption system that uses the same key
  92.             for  encryption  and  decryption.   Sometimes referred to as
  93.             Secret Key Cryptography.
  94.  
  95.      Asymmetric Cryptography:  An encryption system that uses  different
  96.             keys, for encryption and decryption.  Also called Public Key
  97.             Cryptography.
  98.  
  99.  
  100.   AUTHENTICATION TECHNOLOGIES
  101.  
  102.   There are a number of different  classes  of  authentication,  ranging
  103.   from  no  authentication  to  very  strong  authentication.  Different
  104.   authentication mechanisms are  appropriate  for  addressing  different
  105.   kinds of authentication problems, so this is not a strict hierarchical
  106.   ordering.
  107.  
  108.   No Authentication
  109.  
  110.   For completeness, the simplest authentication system is  not  to  have
  111.   any.  A non-networked PC in a private location or a stand-alone public
  112.   workstation  containing  no  sensitive  data  need  not   authenticate
  113.   potential users.
  114.  
  115.   Disclosing Passwords
  116.  
  117.   The  simple  password  check  is  by  far  the  most  common  form  of
  118.   authentication.   Password checks come in many forms: the key may be a
  119.   password memorized by the user, it may be  a  physical  or  electronic
  120.   item  possessed by the user, or it may be a unique biological feature.
  121.   Simple password systems are said to use disclosing  passwords  because
  122.   if  the  password  is  transmitted  over  a network it is disclosed to
  123.   eavesdroppers.  Access keys may be stored on  the  target  system,  in
  124.   which  case  a single breach in system security may gain access to all
  125.   passwords.  Alternatively, as on most systems, the data stored on  the
  126.   system can be enough to verify passwords but not to generate them.
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.                                             Atkinson & Haller  -  Page 3
  135.  
  136.   Non-disclosing Passwords
  137.  
  138.   Non-disclosing password systems have been designed to  prevent  replay
  139.   attacks.    Several  systems  have  been  invented  to  generate  non-
  140.   disclosing passwords.  For example, the  SecurID  Card  from  Security
  141.   Dynamics  uses synchronized clocks for authentication information.  It
  142.   generates a visual display and thus must be in the possession  of  the
  143.   person   seeking  authentication.   The  S/KEY  authentication  system
  144.   developed at Bellcore generates multiple single use passwords  from  a
  145.   single  secret  key.  It  does not use a physical token, so it is also
  146.   suitable for machine-machine authentication.  In  addition  there  are
  147.   challenge-response  systems  in  which a device or computer program is
  148.   used to generate a verifiable response from a non-repeating challenge.
  149.   These systems vary in the sensitivity of the information stored in the
  150.   authenticating host, and thus vary in the security  requirements  that
  151.   must be placed on that host.
  152.  
  153.   Stronger Authentication Systems
  154.  
  155.   The growing use of networked computing environments  has  led  to  the
  156.   need  for  stronger  authentication.  In open networks, many users can
  157.   gain access to any information flowing  over  the  network,  and  with
  158.   additional  effort,  a  user can send information that appears to come
  159.   from another user.
  160.  
  161.   More powerful authentication  systems  make  use  of  the  computation
  162.   capability  of  the two authenticating parties.  Authentication may be
  163.   unidirectional such as most time sharing systems, or it may be  mutual
  164.   in  which case the entity logging in is assured of the identity of the
  165.   host.   Authentication  systems  use  cryptographic   techniques   and
  166.   establish  as  a  part  of  the authentication process a shared secret
  167.   (session key) that can be used for further exchanges.  One example  is
  168.   the  passing  of  a  ticket  that  can be use to obtain other services
  169.   without further authentication.  These authentication systems can also
  170.   provide confidentiality (using encryption) over insecure networks when
  171.   required.
  172.  
  173.   Symmetric Cryptography
  174.  
  175.   Symmetric Cryptography includes all systems that use the same key  for
  176.   encryption and decryption.  This means that knowledge of the key by an
  177.   undesired third party fully compromises  the  confidentiality  of  the
  178.   system.   Therefore,  the  keys  used need to be distributed securely,
  179.   either by courier or perhaps by use of a key distribution protocol, of
  180.   which  the  best  known  is  perhaps  that  proposed  by  Needham  and
  181.   Schroeder.  The widely used Data Encryption Standard (DES)  algorithm,
  182.   which  has  been standardized for use to protect unclassified civilian
  183.   US  Government  information,  is  perhaps  the  best  known  symmetric
  184.   encryption algorithm.
  185.  
  186.   A well known system that addresses insecure open networks as a part of
  187.   a  computing  environment was the Kerberos Authentication Service that
  188.   was developed as part of Project Athena at MIT.  Kerberos is based  on
  189.   Data  Encryption  Standard  (DES)  symmetric key encryption and uses a
  190.   trusted (third party) host that knows the secret keys of all users and
  191.   services,  and thus can generate credentials that can be used by users
  192.   and servers to prove  their  identities  to  other  systems.   As  the
  193.   Kerberos  server  knows all secret keys, it must be physically secure.
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.                                             Atkinson & Haller  -  Page 4
  201.  
  202.   Kerberos session keys can be used to provide  confidentiality  between
  203.   any entities that trust the key server.
  204.  
  205.   Asymmetric Cryptography
  206.  
  207.   In the recent past, a major breakthrough in cryptology has led to  the
  208.   availability  of  Asymmetric  Cryptography.   This  is  different from
  209.   Symmetric Cryptography because different keys are used for  encryption
  210.   and decryption, which greatly simplifies the key distribution problem.
  211.   The best known asymmetric system is based on work by  Rivest,  Shamir,
  212.   and  Adleman  and  is  often  referred  to as "RSA" after the author's
  213.   initials.
  214.  
  215.   SPX is an experimental system that overcomes the  limitations  of  the
  216.   trusted  key  distribution  center of Kerberos by using RSA Public Key
  217.   Cryptography.   SPX  assumes  a   global   hierarchy   of   certifying
  218.   authorities  at  least one of which is trusted by each party.  It uses
  219.   digital signatures that consist of a token encrypted  in  the  private
  220.   key of the signing entity and that are validated using the appropriate
  221.   public key.  The public keys are known  to  be  correct  as  they  are
  222.   obtained  under  the signature of the trusted certification authority.
  223.   Critical parts of the authentication exchange  are  encrypted  in  the
  224.   public keys of the receivers, thus preventing a replay attack.
  225.  
  226.   Digital Signatures
  227.  
  228.   Digital signatures are a comparatively recent addition  to  the  tools
  229.   available  to  protocol  designers.   A  digital  signature performs a
  230.   function analogous to written signatures.  It serves to authenticate a
  231.   piece of data as to the sender and possibly as to the integrity of the
  232.   data.  It is also useful in proving that data in fact originated  with
  233.   a  party even if the party denies having sent it.  A digital signature
  234.   provides authentication without confidentiality and without  incurring
  235.   some of the difficulties in full encryption.  For example, Secure SNMP
  236.   calculates a MD5 cryptographic checksum over a shared secret  item  of
  237.   data  and  the  information  to  be  authenticated.   This serves as a
  238.   digital signature and it is believed to be  very  difficult  to  forge
  239.   such  a digital signature or to invert it to recover the shared secret
  240.   data.  Digital signatures can be used  to  provide  relatively  strong
  241.   authentication   and   are   particularly   useful   in   host-to-host
  242.   communications.
  243.  
  244.   USER TO HOST AUTHENTICATION
  245.  
  246.   There are a number of different approaches to authenticating users  to
  247.   remote  or  networked  hosts.   Two  hazards  are created by remote or
  248.   networked access: First an intruder can eavesdrop on the  network  and
  249.   obtain  user  ids  and  passwords  for a later replay attack.  This is
  250.   called a passive attack.   Second,  an  intruder  can  "take  over"  a
  251.   connection  after  authentication;  this  is  an example of an "active
  252.   attack".
  253.  
  254.   Currently, most systems use plain-text disclosing passwords sent  over
  255.   the  network  (typically  using telnet or rlogin) from the user to the
  256.   remote host.  This system does not provide  adequate  protection  from
  257.   reply  attacks  where an eavesdropper gains remote user ids and remote
  258.   passwords.
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.                                             Atkinson & Haller  -  Page 5
  267.  
  268.   Failure to use at least a non-disclosing password  system  means  that
  269.   unlimited  access  is  unintentionally granted to anyone with physical
  270.   access to the network.  For example, anyone with  physical  access  to
  271.   the  Ethernet  cable  can  impersonate any user on that portion of the
  272.   network.  Thus, when one has plain-text  disclosing  passwords  on  an
  273.   Ethernet, the primary security system is the guard at the door (if any
  274.   exist).  The same problem exists in other  LAN  technologies  such  as
  275.   Token-Ring or FDDI.  In some small internal Local Area Networks (LANs)
  276.   this may be acceptable to take this risk, but it  is  an  unacceptable
  277.   risk in an Internet.
  278.  
  279.   The minimal defense against eavesdropping is to use  a  non-disclosing
  280.   password  system.   Such a system can be run from a dumb terminal or a
  281.   simple communications program (e.g.  CTRM or PROCOMM) that emulates  a
  282.   dumb terminal on a PC class computer.  Using a stronger authentication
  283.   system would certainly defend against passive attacks against remotely
  284.   accessed  systems,  but  at  the  cost of not being able to use simple
  285.   terminals.   It  is  reasonable  to  expect  that   the   vendors   of
  286.   communications  programs  and non user-programmable terminals (such as
  287.   X-Terminals)  would  build  in  non-disclosing  password  or  stronger
  288.   authentication  systems if they were standardized or if a large market
  289.   were offered.
  290.  
  291.   Perimeter defenses are becoming more common.  In  these  systems,  the
  292.   user  first authenticates to the access network, possibly a "firewall"
  293.   host on the Internet, using a non-disclosing password system and  then
  294.   uses  a second system to authenticate to each host, or group of hosts,
  295.   from which service is desired.  This decouples the  problem  into  two
  296.   more easily handled situations.
  297.  
  298.   There are several disadvantages to the perimeter defense, so it should
  299.   be thought of as a short term solution.  The double authentication is,
  300.   in   general,   difficult   or   impossible   for    computer-computer
  301.   communication.   End  to  end  protocols,  which  are  common  on  the
  302.   connectionless Internet, could easily break.   The  perimeter  defense
  303.   must  be  tight  and  complete,  because  if  it  is broken, the inner
  304.   defenses tend to be too  weak  to  stop  a  potential  intruder.   For
  305.   example,  if disclosing passwords are used internally, these passwords
  306.   can be learned by  an  external  intruder  (eavesdropping).   If  that
  307.   intruder  is  able  to penetrate the perimeter, the internal system is
  308.   completely exposed.  Finally, a  perimeter  defense  may  be  open  to
  309.   compromise by internal users looking for shortcuts.
  310.  
  311.   A frequent form of perimeter defense is  the  application  relay.   As
  312.   these  relays  are protocol specific, the IP connectivity of the hosts
  313.   inside the perimeter with the outside world is broken and part of  the
  314.   power of the Internet is broken.
  315.  
  316.   An administrative advantage of  the  perimeter  defense  is  that  the
  317.   number  of  machines  that are on the perimeter and thus vulnerable to
  318.   attack is small.  These machines may be carefully checked for security
  319.   hazards,  but  it  is  difficult (or impossible) to guarantee that the
  320.   perimeter is leak-proof.  The  security  of  a  perimeter  defense  is
  321.   complicated  as  the  gateway machines must pass some types of traffic
  322.   such as electronic mail.  Other network services such as the  Internet
  323.   Network   Time   Protocol   (NTP)  and  FTP  may  also  be  desirable.
  324.   Furthermore the perimeter gateway system must be able to pass  without
  325.   bottleneck the entire traffic load for its security domain.
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.                                             Atkinson & Haller  -  Page 6
  333.  
  334.   In the foreseeable future, the use  of  stronger  techniques  will  be
  335.   required  to  protect against active attacks.  Many corporate networks
  336.   based on broadcast technology such  as  Ethernet  probably  need  such
  337.   techniques.   To  defend  against  an  active  attack,  or  to provide
  338.   privacy, it is necessary to use a protocol  with  session  encryption,
  339.   for example Kerberos, or use an authentication mechanism that protects
  340.   against replay attacks, perhaps using time stamps.  In Kerberos, users
  341.   obtain   credentials  from  the  Kerberos  server  and  use  them  for
  342.   authentication to obtain services from other computers on the network.
  343.   The  computing  power  of the local workstation is used to decrypt the
  344.   credentials (using a key derived from the user-provided password)  and
  345.   store them until needed.
  346.  
  347.   Another approach to remotely accessible networks of  computers  is  to
  348.   consider  externally  accessible  machines  to be "servers" instead of
  349.   general use  workstations,  in  the  Kerberos  sense.   That  is,  the
  350.   Kerberos  authentication server and the server to which the users logs
  351.   in share a secret key. This  secret  can  then  be  used  encrypt  all
  352.   communication between the two machines.  This cryptographically secure
  353.   channel makes  the  accessible  server  a  logical  extension  of  the
  354.   Kerberos  authentication  server.   The  sub-network  of machines thus
  355.   linked becomes, in effect, a larger distributed authentication server.
  356.   Also,  Workstations  that  are  remotely accessible could generate use
  357.   asymmetric technology to encrypt communications.  The  public  key  is
  358.   published  and  well  known to all clients.  A user can use the public
  359.   key to encrypt a simple password that can then be used and the  remote
  360.   system  can  decrypt  the  password  to  authenticate the user without
  361.   risking disclosure of the password while it is in transit.
  362.  
  363.   AUTHENTICATION OF NETWORK SERVICES
  364.  
  365.   In addition to needing to authenticate users and hosts to each  other,
  366.   many network services need or could benefit from authentication.  This
  367.   section describes some approaches to authentication in protocols  that
  368.   are  primarily  host  to  host in orientation.  As in the user to host
  369.   authentication case,  there  are  several  techniques  that  might  be
  370.   considered.
  371.  
  372.   The most common case at present is  to  not  have  any  authentication
  373.   support in the protocol.  Bellovin and others have documented a number
  374.   of cases where existing protocols can  be  used  to  attack  a  remote
  375.   machine because there is no authentication in the protocols.
  376.  
  377.   Some protocols provide for disclosing passwords  to  be  passed  along
  378.   with  the protocol information.  The original SNMP protocols used this
  379.   method and a number of the routing  protocols  continue  to  use  this
  380.   method.   This  method  is  useful  as  a transitional aid to slightly
  381.   increase security and might be appropriate when there is  little  risk
  382.   in having a completely insecure protocol.
  383.  
  384.   However, there are  many  protocols  that  need  to  support  stronger
  385.   authentication  mechanisms.  For example, there was widespread concern
  386.   that SNMP needed stronger authentication than it originally had.  This
  387.   led  to  the  publication  of  the Secure SNMP protocols which support
  388.   optional authentication, using  a  digital  signature  mechanism,  and
  389.   optional   confidentiality,   using   DES   encryption.   The  digital
  390.   signatures used in Secure SNMP are based on appending a  cryptographic
  391.   checksum  to  the  SNMP  information.   The  cryptographic checksum is
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.                                             Atkinson & Haller  -  Page 7
  399.  
  400.   computed using the MD5 algorithm  and  a  secret  shared  between  the
  401.   communicating  parties  so  is  believed  to  be difficult to forge or
  402.   invert.
  403.  
  404.   Digital signature technology has evolved in recent years and should be
  405.   considered   for   applications   requiring   authentication  but  not
  406.   confidentiality.  Digital signatures may use a  single  secret  shared
  407.   among  two  or  more  communicating  parties  or  it might be based on
  408.   asymmetric encryption technology.  The former case would  require  the
  409.   use  of  predetermined  keys  or  the use of a secure key distribution
  410.   protocol, such as that devised  by  Needham  and  Schroeder.   In  the
  411.   latter  case,  the  public  keys  would  need  to be distributed in an
  412.   authenticated manner.  If a general key  distribution  mechanism  were
  413.   available,  support  for optional digital signatures could be added to
  414.   most protocols with little additional expense.   Each  protocol  could
  415.   address the key exchange and setup problem, but that might make adding
  416.   support  for  digital  signatures  more  complicated  and  effectively
  417.   discourage protocol designers from adding digital signature support.
  418.  
  419.   For cases where both authentication and confidentiality  are  required
  420.   on  a  host-to-host  basis, session encryption could be employed using
  421.   symmetric cryptography, asymmetric cryptography, or a  combination  of
  422.   both.   Use  of the asymmetric cryptography simplifies key management.
  423.   Each host would encrypt the  information  and  within  the  host,  the
  424.   existing operating system mechanisms would provide protection.
  425.  
  426.   In some  cases,  possibly  including  electronic  mail,  it  might  be
  427.   desirable  to  provide  the security properties within the application
  428.   itself in a manner that  was  truly  user-to-user  rather  than  being
  429.   host-to-host.   The Privacy Enhanced Mail (PEM) work is employing this
  430.   approach.
  431.  
  432.   FUTURE DIRECTIONS
  433.  
  434.   Systems   are   moving   towards   the   cryptographically    stronger
  435.   authentication  protocols described in the first paragraph.  This move
  436.   has two implications for future systems.  We can  expect  to  see  the
  437.   introduction  and  eventually the widespread use of public key crypto-
  438.   systems.  Session authentication, integrity, and  privacy  issues  are
  439.   growing  in  importance. As computer-to-computer communication becomes
  440.   more important, protocols that provide simple  human  interfaces  will
  441.   become  less  important.  This is not to say that human interfaces are
  442.   unimportant; they are very important.  It means that these  interfaces
  443.   are  the  responsibility  of  the  applications,  not  the  underlying
  444.   protocol.  Human interface design is beyond the scope of this memo.
  445.  
  446.   The use of public key crypto-systems for user to  host  authentication
  447.   solve  many security issues, but unlike simple passwords, a public key
  448.   cannot be memorized.  Current public keys are about 500 bits long, and
  449.   it  is likely that in the near future longer keys will be used.  Thus,
  450.   users might have to carry their  private  keys  in  some  electrically
  451.   readable form.  The use of read-only storage, such as a floppy disk or
  452.   a magnetic stripe card provides such storage, but it might require the
  453.   user  to  trust  their  private  keys to the reading device.  Use of a
  454.   smart card, a portable device  containing  both  storage  and  program
  455.   might  be preferable.  These devices have the potential to perform the
  456.   authenticating operations  without  divulging  the  private  key  they
  457.   contain.   They  can  also  interact with the user requiring a simpler
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.                                             Atkinson & Haller  -  Page 8
  465.  
  466.   form of authentication to "unlock" the card.
  467.  
  468.   The use of public key crypto-systems for host to  host  authentication
  469.   appears  not  to have the same key memorization problem as the user to
  470.   host case does.  A multiuser  host  can  store  its  key(s)  in  space
  471.   protected from users and obviate that problem.  Single user inherently
  472.   insecure systems, such as PCs and  Macintoshes,  remain  difficult  to
  473.   handle but the smart card approach should also work for them.
  474.  
  475.   The implications of this taxonomy  are  clear.   Strong  cryptographic
  476.   authentication  is  needed  in  the  near  future  for many protocols.
  477.   Public key technology should be used when it is  practical  and  cost-
  478.   effective.   In the short term, the use of disclosing password systems
  479.   should be phased out in favor of non-disclosing  systems  and  digital
  480.   signatures.
  481.  
  482.   SECURITY CONSIDERATIONS
  483.  
  484.     The entire Internet Draft discusses Security Considerations in  that
  485.   it  discusses  authentication  technologies  and  needs.  There are no
  486.   security issues regarding the public release of this draft.
  487.  
  488.   EXPIRATION
  489.  
  490.     This Internet Draft expires on February 1, 1994.
  491.  
  492.   AUTHORS' ADDRESSES
  493.  
  494.      Neil Haller              <nmh@thumper.bellcore.com>
  495.      Bell Communications Research
  496.      445 South Street  -- MRE 2Q-280
  497.      Morristown, NJ 07962-1910
  498.  
  499.      Randall Atkinson         <atkinson@itd.nrl.navy.mil>
  500.      Code 5544
  501.      Naval Research Laboratory
  502.      Washington, DC 20375
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.